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We study the problem of deriving a specification for a third-party component, based on the specifi- 
cation of the system and the environment in which the component is supposed to reside. Particularly, 
we are interested in using component specifications for conformance testing of black-box compo- 
nents, using the theory of input-output conformance (ioco) testing. We propose and prove sufficient 
criteria for decompositionality, i.e., that components conforming to the derived specification will al- 
ways compose to produce a correct system with respect to the system specification. We also study the 
criteria for strong decomposability, by which we can ensure that only those components conforming 
to the derived specification can lead to a correct system. 



1 Introduction 

Enabling reuse and managing complexity are among the major benefits of using compositional ap- 
proaches in software and systems engineering. This idea has been extensively adopted in several different 
subareas of software engineering, such as product-line software engineering. One of the cornerstones of 
the product-line approach is to reuse a common platform to build different products. This common plat- 
form should ideally comprise different types of artifacts, including test-cases, that can be re-used for 
various products of a given line. In this paper, we propose an approach to conformance testing, which 
allows to use a high-level specification and derive specifications for to-be-developed components (or sub- 
systems) given the platform on which they are to be deployed. We call this approach decompositional 
testing and refer to the process of deriving specifications as quotienting (inspired by its counterpart in 
the domain of formal verification). 

We develop our approach within the context of input-output conformance testing (ioco) ||T3ll , a 
model-based testing theory using formal models based on input-output labeled transition systems (IOLTSs) 
An implementation i is said to conform to a specification s, denoted by i ioco s, when after each trace in 
the specification, the outputs of the implementation are among those prescribed by the specifications. 

For a given platform (environment) e, whose behavior is given as an IOLTS, a quotient of a speci- 
fication s by the platform e, denoted by s/g, is the specification that describes the system after filtering 
out the effect of e. The structure of a system consisting of e and unknown component c is represented 
in Figure [TJ whose behavior is described by a given specification s. We would like to construct s/ g such 
that it captures the behavior of any component c which, when deployed on e (put in parallel and possibly 
synchronize with e) conforms to s. Put formally, s/g is the specification which satisfies the following 
bi-implication: 
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Vc,e. c ioco s/g 44> cjleiocos 

The criteria for the implication from left to right, which is essential for our approach, are called de- 
composability. The criteria for the implication from right to left guarantee that quotienting produces 
the precise specification for the component and is called strong decomposability. We study both criteria 
in the remainder of this paper. Moreover, we show that strong decomposability can be combined with 
on-the-fly testing, thereby avoiding constructing the witness to the decomposability explicitly upfront. 
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Figure 1: Strucure of a system composed of platform e and component c whose behavior is defined by 
a given specification s. The language of platform e comprises (I' e U U v ) U {U' e \Jl v ). Similarly, (I' C UI V ) U 
(U' c U U v ) is the language of component c. The platform e and component c interface via I v and U v which 
are hidden from the viewpoint of an external observer. 



Related Work. The study of compositional and modular verification for various temporal and modal 
logics has attracted considerable attention and several compositional verification techniques have been 
proposed for such logics; see, e.g., El [71 [El 0. Decompositional reasoning aims at automatically decom- 
posing the global property to be model checked into local properties of (possibly unknown) components, 
a technique that is often called quotienting. The notion of quotient introduced in the present paper is 
inspired by its corresponding notion in the area of (de)compositional model-checking, and is substan- 
tially adapted to the setting for input-output conformance testing, e.g., by catering for the distinction 
between input and output actions and taking care of (relative) quiescence of components. In the area of 
model-based testing, we are aware of a few studies dedicated to the issue of (de)composition 1131151 \T4\. 
of which we give an overview below. 

In the compositionality of the ioco-based testing theory is investigated. Assuming that implemen- 
tations of components conform to their specifications, the authors investigate whether the composition of 
these implementations still conforms to the composition of the specifications. They show that this is not 
necessarily the case and they establish conditions under which ioco is a compositional testing relation. 

In J21 , Frantzen and Tretmans study when successful integration of components by composing them 
in certain ways can be achieved. Successful integration is determined by two conditions: the integrated 
system correctly provides services, and interaction with other components is proper. For the former, 
a specification of the provided services of the component is assumed. Based on the ioco-relation, the 
authors introduce a new implementation relation called eco, which allows for checking whether a com- 
ponent conforms to its specification as well as whether it uses other components correctly. In addition, 
they also propose a bottom-up strategy for building an integrated systems. 

Another problem closely related to the problem we consider in this paper is testing in context, also 
known as embedded testing |[T4ll . In this setting, the system under test comprises a component c which is 
embedded in a context u. Component c is isolated from the environment and all its interactions proceed 
through u (which is assumed to be correctly implemented). The implementation i and specification s of 
the system composed of u and c, are assumed to be available. The problem of testing in context then 
entails generating a test suite that allows for detecting incorrect implementations i of component c. 
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Although testing in context and decomposability share many characteristics, there are key differences 
between the two. We do not restrict ourselves to embedded components, nor do we assume the platforms 
to be fault-free. Contrary to the testing in context approach, decomposing a monolithic specification is 
the primary challenge in our work; testing in context already assumes the specification is the result of 
a composition of two specifications. Moreover, in testing in context, the component c is tested through 
context u whereas our approach allows for testing the component directly through its deduced specifi- 
cation. As a result, we do not require that the context is always available while testing the component, 
which is particularly important in case the platform is a costly resource. 

For similar reasons, asynchronous testing ifTTl [H [15]], which can be considered as some form of 
embedded testing, is different from the work we present in this paper. 

Structure. We give a cursory overview of ioco-based formal testing in Section [2] The notions of de- 
composability and strong decomposability are formalized in Section [3] We present sufficient conditions 
for determining whether a given specification is decomposable in Section [4] and whether it is strongly 
decomposable in Section [5] We conclude in Section [6] Additional examples and results, together with 
all proofs for the lemmata and theorems can be found in [9 J. 

2 Preliminaries 

Conformance testing is about checking that the observable behavior of the system under test is included 
in the prescribed behavior of the specification. In order to formally reason about conformance testing, we 
need a model for reasoning about the behaviors described by a specification, and assume that we have 
a formal model representing the behaviors of our implementations, so that we can reason about their 
conformance mathematically. 

In this paper, we use variants of the well-known Labeled Transition Systems as a behavioral model 
for both the specification and the system under test. The Labeled Transition System model assumes that 
systems can be represented using a set of states and transitions, labeled with events or actions, between 
such states. A tester can observe the events leading to new states, but she cannot observe the states. We 
assume the presence of a special action X, which we assume is unobservable to the tester. 

Definition 1 (IOLTS) An input-output labeled transition system (IOLTS) is a tuple (S,I,U,— s), where 
S is a set of states, I and U are disjoint sets of observable inputs and outputs, respectively, ->CSx (ID 
U U {t}) x S is the transition relation (we assume X ^ ID U), and s £ S is the initial state. The class of 
IOLTSs ranging over inputs I and outputs U is denoted I0LTS(7, U). 

Throughout this section, we assume an arbitrary, fixed IOLTS (S,I,U,-^-,s), and we refer to this 
IOLTS by referring to its initial state s. We write L for the set IU U. Let s,s' G S and x G LL){x}. In line 
with common practice, we write s A- s' rather than (s,x,s') G— >. Furthermore, we write s A- whenever 
s — > j' for some s f G S, and s ^> when not s A. A word is a sequence over the input and output symbols. 
The set of all words over L is denoted L* , and £ is the empty word. For words a,p G L* , we denote the 
concatenation of a and p by op. The transition relation is generalized to a relation over words by the 
following deduction rules: 
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We adopt the notational conventions we introduced for — > for =>. A state in the IOLTS s is said to 
diverge if it is the source of an infinite sequence of T-labeled transitions. The IOLTS s is divergent if one 
of its reachable states diverges. Throughout this paper, we confine ourselves to non-divergent IOLTS s. 

Definition 2 Let s' G S and S' C S. The set of traces, enabled actions and weakly enabled actions for s 
and S' are defined as follows: 

• traces(i) = {a G L* \ s =§>}, and traces(S') = |J traces(V). 

s'es' 

• init(i) = {xGLU{t} I s A}, and init(5") = U init(j'). 

s'es 1 

• Sinit(^) = {xeL\s =»}, and Sinit(5") = |J Sinit(j'). 

s'es' 

Quiescence and Suspension Traces. Testers often not only have the power to observe events produced 
by an implementation, they can also observe the absence of events, or quiescence |[T3l . A state s G S is 
said to be quiescent if it does not produce outputs and it is stable. That is, it cannot, through internal 
computations, evolve to a state that is capable of producing outputs. Formally, state s is quiescent, 
denoted 8(s), whenever init(s) C /. In order to formally reason about the observations of inputs, outputs 
and quiescence, we introduce the set of suspension traces. To this end, we first generalize the transition 
relation over words to a transition relation over suspension words. LetLg denote the set LU {8}. 

s ^s' S(s) s ^ s s" s"^ s s> 

o, S ap . 

s s s =^g s s =^s s 

The following definition formalizes the set of suspension traces. 

Definition 3 Let s € S and S' C S. The set of suspension traces for s, denoted Straces(^) is defined as 

the set {a £L* s \s we set Straces(5 ,/ ) = IJ Straces(V). 

s'es' 



Input-Output Conformance Testing with Quiescence. Tretmans' ioco testing theory |[T3l formalizes 
black box conformance of implementations. It assumes that the behavior of implementations can always 
be described adequately using a class of IOLTSs, called input output transition systems; this assumption 
is the so-called testing hypothesis. Input output transition systems are essentially plain IOLTSs with the 
additional assumption that inputs can always be accepted. 

Definition 4 (IOTS) Let (S,I,U,—>-,s) be an IOLTS. A state s G S is input-enabled iff I C Sinitfs); the 
IOLTS s is an input output transition system (IOTS) iff every state s G S is input-enabled. The class of 
input output transition systems ranging over inputs I and outputs U is denoted IOTS(7, U). 

While the ioco testing theory assumes input-enabled implementations, it does not impose this require- 
ment on specifications. This facilitates testing using partial specifications, i.e., specifications that are 
under-specified. We first introduce the main concepts that are used to define the family of conformance 
relations of the ioco testing theory. 



Definition 5 Let {S, I,U,—-,s) be an IOLTS. Let seS,S'CS and let o G L* g . 
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• s after a = {s 1 G 5 | s =§>g s'}, and S' after a = \J s' after a. 

s'eS' 

• out(s) = {* g L 5 \ 7 | S and out(5") = |J out(s'). 

s'eS' 

The family of conformance relations for ioco are then defined as follows, see also lfl3l . 

Definition 6 (ioco) Let (R,I, U,—>,r) be an IOTS representing a realization of a system, and let IOLTS 
(S,I, U, —>,s) be a specification. Let F C Lt. We say that r is input output conform with specification s, 
denoted f iocop s, iff 

Va G F : out(r after a) C out(s after a) 

The iocof conformance relation can be specialized by choosing an appropriate set F. For instance, in 
a setting with F = Straces(^), we obtain the ioco relation originally defined by Tretmans in |[T2l . The 
latter conformance relation is known to admit a sound and complete test case generation algorithm, 
see, e.g., lfl2l[T3l . Soundness means, intuitively, that the algorithm will never generate a test case that, 
when executed on an implementation, leads to a fail verdict if the test runs are in accordance with the 
specification. Completeness is more esoteric: if the implementation has a behavior that is not in line with 
the specification, then there is a test case that, in theory, has the capacity to detect that non-conformance. 

Suspension automata. The original test case generation algorithm by Tretmans for the ioco relation 
relied on an automaton derived from an IOLTS specification. This automaton, called a suspension au- 
tomaton, shares many of the characteristics of an IOLTS, except that the observations of quiescence are 
encoded explicitly as outputs: 8 is treated as an ordinary action label which can appear on a transition. 
In addition, Tretmans assumes these suspension automata to be deterministic: any word that could be 
produced by an automaton leads to exactly one state in the automaton. 

Definition 7 (Suspension automaton) A suspension automaton( SA ) is a deterministic IOLTS (S, I,UU 
{8},— )■, s); that is, for all s G 5 and all o G L* , we have \s after o\ < 1. 

Note that determinism implies the absence of % transitions. In |fl2||. a transformation from ordinary 
IOLTSs to suspension automata is presented; the transformation ensures that trace-based testing using 
the resulting suspension automaton is exactly as powerful as ioco-based testing using the original IOLTS. 

The transformation is essentially based on the subset construction for determinizing automata. Given 
an IOLTS, the transformation A defined below converts any IOLTS into an SA. 

Definition8 Let (S,I,U,->,s) G IOLTS(/,t/). The SA A(s) = (Q,I,U\J{8},->,q) is defined as: 

• £ = P(S)\{0}. 

• q = s after e. 

• — 7-C Q x Lg x Q is the least relation satisfying: 

x£L q£Q q^Q 
q A {s' G S | 3s G q»s A s'} q \ {s G q \ 8(s)} 

Example 1 Consider the IOLTS s depicted in Figure^on page^57^ The IOLTS s is a specification of a 
malfunctioning vending machine which sells tea for one euro coin (c). After receiving money, it either 
delivers tea (t), refunds the money (r) or does nothing. Its suspension automaton A(s), with initial state 
q, is depicted next to it. Note that the suspension traces of s and the traces of suspension automaton A(s) 
are identical. 
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In general, a suspension automaton may not represent an actual IOLTS; for instance, in an arbitrary 
suspension automaton, it is allowed to observe quiescence, followed by a proper output. This cannot 
happen in an IOLTS. In [16], the set of suspension automata is characterized for which a transformation 
to an IOLTS is possible. Such suspension automata are called valid. Proposition 1 of lfl6l states that for 
any IOLTS s, the suspension automaton A(j) is valid. Conversely, Theorem 2 of lPT6l states that any valid 
suspension automaton has the same testing power (with respect to ioco) as some IOLTS. This essentially 
means that the class of valid suspension automata can be used safely for testing purposes. 

Parallel Composition. A software or hardware system is usually composed of subunits and modules 
that work in an orchestrated fashion to achieve the desired overall behavior of the software or hardware 
system. In our setting, we can formalize such compositions using a special operator _|| _ on IOLTSs: two 
IOLTSs can interact by connecting the outputs sent by one IOLTS to the inputs of the other IOLTS. We 
assume that such inputs and outputs are taken from a shared alphabet of actions. For the non-common 
actions the behavior of both IOLTSs is interleaved. 

Definition 9 (parallel composition) Let (Si,Ii,Ui,— >i,*i) and (S2,h, Uj, —^2,^2) be two IOLTSs with 
disjoint sets of input labels I\ and I 2 , and disjoint sets of output labels U\ and U%. The parallel composi- 
tion ofs\ and s~2, denoted s~\\s~2 is the IOLTS (Q,I,U,— >,si\\s2), where: 

• Q = {*l||*2 I *i G Si,s 2 6 S 2 }. 

• I = (h UI 2 ) \ (Ui U U 2 ) and U = U { U U 2 . 

• — >Q Q x (LU {t}) x Q is the least relation satisfying: 

s\ — H s\ x L2 S2 ^>2 s'2 X^lL\ 

S\ ||S2 — > s[ ||*2 Si ||*2 Si \\s' 2 

S 2 -^2S 2 X^Z 

II X v / II / 

S\ 11*2 > *i ||*2 

The interaction between components is typically intended to be unobservable by a tester. This is not 
enforced by the parallel composition, but can be specified by combining parallel composition with a 
hiding operator, which is formalized below. 

Definition 10 (hiding) Let (S,I, U,—t,s) be an IOLTS, and let V C U. The IOLTS resulting from hiding 
events from the set V, denoted by hide[V] ins is the IOLTS (S,I, U\V, —)■',*), where — >' is defined as the 
least relation satisfying: 

s^s' x^V s^s' xeV 

hide [V] in j -V hide [V] in s' hide [V] in s - V hide [V] in s' 

Note that the hiding operator may turn non-divergent IOLTSs into divergent IOLTSs. As divergence is 
excluded from the ioco testing theory, we must assume such divergences are not induced by composing 
two implementations in parallel and hiding all successful communications. Since implementations are 
assumed to be input enabled, this can only be ensured whenever components that are put in parallel never 
produce infinite, uninterrupted runs of outputs over their alphabet of shared output actions. Implemen- 
tations adhering to these constraints are referred to as shared output bounded implementations. From 
hereon, we assume that all the implementions considered are shared output bounded. 
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3 Decomposibility 

Software can be constructed by decomposing a specification of the software in specifications of smaller 
complexity. Reuse of readily available and well-understood platforms or environments can steer such a 
decomposition. Given the prevalence of such platforms, the software engineering and associated testing 
problem thus shifts to finding a proper specification of the system from which the platform behavior has 
been factored out. Whether this is possible, however, depends on the specification; if so, we say that a 
specification is decomposable. 

The decomposability problem requires known action alphabets for both the specification and the 
platform. Hence, we first fix these alphabets and illustrate how these are related. Hereafter, L s denotes 
the action alphabet of the specification s and L e denotes the action alphabet of the platform e. The actions 
of L e not exposed to s are contained in action alphabet L v , i.e., we have L v = L e \L s . The action alphabet 
of the quotient will be denoted by L, i.e. L = (L s \L e )UL v . The relation between the above alphabets is 
illustrated in Figure [T] in the introduction. 

Definition 11 (Decomposability) Let s £ IOLTS(/ 4 , U s ) be a specification, and let e 6 IOTS(/ e , U e ) be 

an implementation. Let L v = I v U U v be a set of actions of e not part of s. Specification s is said to be 
decomposable for IOTS e iff there is some specification s' € IOLTS((/ J \/ f .) U/ v , (U s \ U e ) UU V ) for which 
both: 

• 3c E IOTS((/,\/ a ) U/ V) (17, \ U e ) U C7 V ) •cioco s 1 , and 

• VcG IOTS((/ e \/ e )U/ v ,(f7 e \f7 e )Uf7 v ) •cioco s 1 =>• hide [L v ] in c\\e ioco s 

Decomposability of a specification s essentially ensures that a specification s 1 for a subcomponent ex- 
ists that guarantees that every ioco-correct implementation of it is also guaranteed to work correctly in 
combination with the platform. 




(a) IOLTS s (b) SA A(s) (c) IOTS e (d) IOTS f 




(e) IOLTS m (f) IOLTS p (g) IOTS c 

Figure 2: A specification of a vending machine (s), two behavioral models of an implemented money 
component (e and r) and two specifications for a drink component (m and p) with the behavioral model 
of an implementation of the drink component (c). 



Example 2 Consider IOLTSs depicted in Figure^ The IOTS e 2(c) presents the behavioral model of an 
environment which after receiving a coin (c) either orders drink ( order) or does nothing. Upon receiving 
an error signal (error), never refunds the money (r). Component e interacts with another component 
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through actions 'order' and 'error'; together, the components implement a vending machine for which 



IOLTS s 2(a) is the specification. The IOLTS m 2(e) is a specification of a drink component which 



delivers tea after receiving a drink order. If it encounters a problem in delivering the drink, it signals 
an error. Specification m guarantees that the combination of component e with any drink component 
implementation conforming to in, also conforms to s. 

It may, however, be the case that an implementation, in combination with a given platform, perfectly 
adheres to the overall specification s, and, yet fails to pass the conformance test for s'. As a consequence, 
non-conformance of an implementation to s 1 may not by itself be a reason to reject the implementation. 



Example 3 Consider IOLTSs in Figure^ The IOLTS m 2(e)\ is a witness for decomposability of IOLTS 
|2f a ) for platform 12(c) Thus, any compound system built oflOTS e and a component conforming to m 
is guaranteed to be in conformance with IOLTS s. Now, consider IOTS c \2(g)\ which incorrectly imple- 



ments the functionality specified in IOLTS m 2(e) as it sends 'error' twice. Observe that, nevertheless, 
hide [{error, order}] inc||e still conforms to s. 

It is often desirable to consider specifications s 1 for which one only has to check whether an imple- 
mentation c adheres to s 1 , i.e., specifications for which it is guaranteed that a failure of an implementation 
c to comply to s 1 also guarantees that the combination c\\e will violate the original specification s. We 
can obtain this by considering a stronger notion of decomposability. 



Definition 12 (Strong Decomposability) Let s£ \OUS(I,U) be a specification, andlet e€ \OTS(I e ,U e ) 
be an implementation. Let L v = I v U U v be a set of actions ofe not part ofs. Specification s is said to be 
strongly decomposable for IOTS e iff there is some specification s 1 € IOLTS((/ s \/ e ) U/ v , (U s \ U e ) UU V ) 
for which both: 

• 3c £ IOTS((/ s . \/ e ) U/ v , (17, \ U e ) U U v ) • cioco s 1 , and 

• Vc G IOTS((/ s \I e ) U/ v , (U s \ U e ) U U v ) •cioco s 1 <=^ hide[L v ]inc||e ioco s 

Example 4 Consider the IOLTSs p and e in Figure |2[ specification p is such that the combination of 
component e with any shared output bounded component that does not conform to p, fails to comply to s. 



4 Sufficient Conditions for Decomposibility 

Checking whether a given specification is decomposable is a difficult problem. However, knowing that a 
specification is decomposable in itself hardly helps a design engineer. Apart from the question whether 
a specification is decomposable, one is typically interested in a witness for the decomposed specifica- 
tion, or quotient. Our approach to the decomposability problem is therefore constructive: we define a 
quotient and we identify several conditions that ensure that the quotient we define is a witness for the 
decomposability of a given specification. 

One of the problems that may prevent a specification from being decomposable for a given platform 
e is that the latter may exhibit some behavior which unavoidably violates the specification s. We shall 
therefore only consider platforms for which such violations are not present. We formalize this by check- 
ing whether the behavior of e is included in the behavior of s; that is, we give conditions that ensure 
that e in itself cannot violate the given specification s. Moreover, we assume that the input-enabled 
specification of e is available. 
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Assuming that the behavior of e is included in the behavior of the given specification s, we then pro- 
pose a quotient s 1 of s for e and prove sufficient conditions that guarantee that s is indeed decomposable 
and s 1 is a witness to that. 

4.1 Inclusion relation 

We say that the behavior of a given platform e is included in a specification s if the outputs allowed by 
s subsume all outputs that can be produced by e. For this, we need to take possible communications 
between e and the to-be-derived quotient over the action alphabet L v into account. Another issue is that 
we are dealing with two components, each of which may be quiescent. If component e is quiescent, its 
quiescence may be masked by outputs from the component with which it is supposed to interact. We 
must therefore consider a refined notion of quiescence. We say state s in specification s is relatively 

quiescent with respect to alphabet L e , denoted by 8g{s), if s produces no output of L e , i.e. out(s) nL e = 0. 

8- 

Analogous to 8, the suspension traces of s can be enriched by adding the rule s s for 8g(s) to be 
able to formally reason about the possibility of being relatively quiescent with respect to L e . We write 
Straces^s) to denote this enriched set of suspension traces of s. 

Since the suspension traces of s and e differ as a result of different alphabets, we introduce a projec- 
tion operator which allows us to map the suspension traces of s to suspension traces of e. The operator 
-l Le is defined as (xo)^ L = x<J^ Le if x G L e ; (xg)^ l = 8(0^), if x G {8, Sg}; otherwise, {xa)^ =o^ Le . 

Definition 13 Let IOTS (S e ,I e ,U e ,^,e) be an implementation. Let IOLTS (S s ,I s ,U s ,^,s) be a specifi- 
cation. We say the behavior ofe is included in s, denoted by e incl s iff 

Va G Straces^s) : out(hide[L v ]ine after ) C out(s after a) 

Example 5 Consider the IOLTSs in Figure [2] We have e incl s. Consider the IOLTS r which has the 
same functionality with IOLTS e except that upon receiving an error signal (error), it may or may not 
refund the money ( r). The behavior off is not included in s, because of observing the output r in r after 
executing (ct)^ while s after execution of ct reaches to a quiescent state. 

4.2 Quotienting 

We next focus on deriving a quotient of the specification s, factoring out the behavior of the platform e. 
A major source of complexity in defining such a quotient is the possible non-determinism that may be 
present in s and e. We largely avert this complexity by utilizing the suspension automata underlying s 
and e. 

Another source of complexity is the fact that we must reason about the states of two systems running 
in parallel; such a system synchronizes on shared actions and interleaves on non-shared actions. We 
tame this conceptual complexity by formalizing an executes operator which, when executing a shared 
or non-shared action, keeps track of the set of reachable states for the (suspension automata) of s and e. 
Formally, the executes operator is defined as follows. 

Definition 14 Let (Q S ,I S ,U S U {8},— > s ,<js) be a suspension automaton underlying specification IOLTS 
s, and let (Q e ,I e ,U U {5},— > e ,Ge) be a suspension automaton underlying platform IOLTS e. Let q G 
x Q e ) be a non-empty collection of sets and let x G L s \ (L e \ L v ). 
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|J IJ { Wide) I s q' s and e -^k e q' e ) if x G L v 
(JEL* (s,e)eq 

„ executes .v { U [j i^'e) \ q' s and e ^ e q' e } tfx^U 

aeZ* (s,e)eq 

U |J { Wsrfe) I s <?'y "^e tf'J If* = S 

GEL* (s,e)€q 

Using the executes operator, we have an elegant construction of an automaton, called a quotient au- 
tomaton, see below, which allows us to define sufficient conditions for establishing the decomposability 
of a given specification. 

Definition 15 (Quotient Automaton) Let ( Q s , I s , U s U { 5}, —} s ,q s ) be a suspension automaton underly- 
ing specification s, and let (Q e ,I e ,U e U {5},— > e ,q e ) be a suspension automaton underlying platform e. 
The quotient ofsby e, denoted by s/g is a suspension automaton {Q,I, U U {8}, — >,q) where: 

• Q = {HQs x Qe) \{0})U£ 5 , where Q S = {q S \q£ HQs *Qe),q^ ®};forqt Q s , we set q~ x = q 
and for q§ G Qg, we set qg 1 = q. 

• q = {{qs,q e )}- 

• / = (/, \ Z e ) U (V e \ U s ) and U = {U s \ U e ) U {8} U (l e \ I s ). 

• — 7-C Q x L x Q is the least set satisfying: 

a£l q~ l executes a ^ x£U v q ^ Qs q 1 executes x / 

y 1 \\ x — \ : l^i J 



a 



q—^q 1 executes a q — > q 1 executes x 

xeU\U v V(j,e) e q,o G traces^) ntraces(e) n (L* s \L* g 8) : x G out(s after a) 

q A q~ l executes x 

y(s,e) G q~ Y ,o G traces(5') ntraces(e) : 5 G outfj after a) 

s~ ™ 

q^r q 1 executes 8 

We briefly explain the construction of a quotient automaton. A non-shared input action is added to a 
state in the quotient automaton s/ g if an execution of the corresponding state in e leads to a state in s at 



which that action is enabled in combination with the second case in Definition 14 1. A shared input 



action obeys the same rule except that a state of e has to be reachable where that input action is taken (I\ , 



in combination with the first case in Definition 14 1. Note that a shared input action of s/ s is an output 



action from the viewpoint of e. In contrast, a non-shared output action is allowed at a state of s/ s only 
if it is allowed by s after any possible execution of e (U2) and a similar rule is applied to quiescence 
(5i). Analogous to the shared input actions, a shared output action is considered as an action of a state 
whenever a valid execution of the correspondent states in e leads to a state at which that output action 
is enabled (U\). Because the shared actions are hidden in s, a shared output action, in s/ g , may also be 
enabled at a state reached by 8 transitions. Such a sequence of events is invalid due to the definition 
of quiescence. The observed problem is solved by adding a special set of states Q§ to the states of the 
quotient automaton. These states represent quiescent states corresponding to the reachable states after 
executing 8 in su. Moreover, no shared output action is added to these states. 
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Figure 3: Two quotient automata derived using Definition 15 



The quotient automaton derived from specification s and platform e is a suspension automaton: it 
is deterministic and it has explicit 8 labels. Yet, the quotient automata we derive are not necessarily 
valid suspension automata. (As we recalled in Section [2| only valid suspension automata have the same 
testing power as ordinary IOLTSs.) We furthermore observe that there some quotient automata that are 
valid suspension automata but nevertheless only admit non-shared output bounded implementations as 
implementations that conform to the quotient. As observed earlier, such implementations unavoidably 
give rise to divergent systems when composed in parallel with the platform. 

Example 6 Consider SAs depicted in Figure [5] IOLTSs s and e in Figure [2] and IOLTS I derived by 
removing the internal transition from state s\ to the initial state in s. SA r is the quotient of s by e. 
Likewise, SA i is the quotient of I by e. Suspension automata f and i are valid SA regarding the definition 
of validity of suspension automata presented in H16\l . Assume an arbitrary shared output bounded IOTS 
c whose length of the longest sequence on the shared output is n, i.e. out(c after a) C {tea, 8} for a = 
{error}' 1 . Clearly, c ipci) i, because out(/ after a) = {error}. However, for any n>0, there is always a 
shared output bounded IOTS that conforms to f. 

In view of the above, we say that a quotient automaton is valid if it is a valid suspension automaton and 
strongly non-blocking. 

Definition 16 Let s/g be a quotient automaton derived from a specification s and an environment e. We 
say that s/g is valid iff both: 

• s/ s is a valid suspension automaton, and 

• s/g is strongly non-blocking, i.e. \/q G s~/g»ou\.(q) f]((U \ U v ) U {8}) 7^ 0. 

Strongly non-blocking ensures that the quotient automaton always admits a shared output bounded im- 
plementation that conforms to it. Furthermore, valid quotient automata are, by definition, also valid 
suspension automata. Since every valid suspension automaton underlies at least one IOLTS, we there- 
fore have established a sufficient condition for the decomposability of a specification. 

Theorem 1 Let s £ IOLTS(/ 4 , U s ) be a specification and let e £ IOTS(7 e , U e ) be an environment. Then s 
is decomposable for e ifs/g is a valid quotient automaton and e incl s. 

Note that the IOLTS underlying the quotient automaton is a witness to the decomposability of the spec- 
ification; we thus not only have a sufficient condition for the decomposability of a specification but also 
a witness for the decomposition. 
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Figure 4: A schematic view of the EFT Switch, a suspension automata of simplified behavioral models 
of the EFT switch s and an implementation of the financial component e, and the quotient of s w.r.t. e 



4.3 Example 

To illustrate the notions introduced so far, we treat a simplified model of an Electronic Funds Transfer 
(EFT) switch, which we have studied and tested using ioco-based techniques HI . A schematic view of 



this example is depicted in Figure 4(a) An EFT switch provides a communication mechanism among 
different components of a card-based financial system. On one side of the EFT switch, there are compo- 
nents, with which the end-user deals, such as Automated Teller Machines (ATMs), Point-of-Sale (POS) 
devices and e-Payment applications. On the other side, there are banking systems and the inter-bank 
network connecting the switches of different financial institutions. 

The various involving parties in every transaction performed by an EFT switch in conjunction with 
the variety of financial transactions complicate the behavioral model of the EFT switch. Similar to any 
other complex software system, the EFT switch comprises many different components, some of which 
can be run individually. 

A part of the simplified communication model of the EFT switch with a banking system in the 



purchase scenario is depicted in Figure 4(b) The scenario starts by receiving a purchase request from a 
POS; this initial part of the scenario is removed from the model, for the sake of brevity. Subsequently, the 
EFT switch sends a purchase request (p-rq) to the banking system. The EFT switch will reverse {revj-q) 
the sent purchase request if the corresponding response (p~rs) is not received within a certain amount of 
time (e.g, an internal time-out occurs, denoted by t). Due to possible delays in the network layer of the 
EFT switch, an external observer (tester) may observe the reverse request of a purchase even before the 



purchase request which is pictured in Fig 4(b) 



The EFT switch is further implemented in terms of two components, namely, the financial component 
and the reversal component. A simplified behavioral model of the financial component is given in Figure 
4(c)| Comparing the two languages of s and e, t action (representing time-out) is considered as an internal 
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interface between e and a to-be-developed implementation of the reversal component. Observe that 
for every sequence a in {p jrq{8 e \rev jrq)* , p jrq{8 e \rev J*q)* rev jrq{8\8 e )* , pjrq p_rs(8 e \rev_rq)* (8\8 e )* , 
(8 e \rev_rq)* , (8 e \rev _rq)* rev _rq{rev _rq\p _rq)* (8\8 e )*} , it holds that out(hide[?] ine after <J± L ) Q 
out(s after a); thus, the behavior of e is included in s. We next instigate investigate decomposability of 
s with e, by constructing the quotient s/ s . Note that t is the only shared action which is an input action 
from the view point of s/g. The resulting quotient automaton, obtained by applying Definition 15 to s 
and e is depicted in Figure [4(d)] We illustrate some steps in its derivation. The initial state of the quotient 
automaton is defined as the {(s,e)}. Below, we illustrate which of the rules of Definition 15 are possible 
from this initial state; doing so repeatedly for all reached states will ultimately produce the reachable 
states of the quotient automaton. 

1. We check the possibility of adding input transitions to the initial state, i.e. qo = {(s,e)}. Following 
qo executes t = {(si,^)} and deduction rule ly in Definition 



15 



the transition qo — > q\ is added 



2. 



to the transition relation of s i g where qi = { (s{ , ^2)} (state 1 in Figure 4(d) ). 

We check the possibility of adding output transitions to go = {(s,e)}. We observe that revjrq e 
out(s after a) for every o G {e,p-rq,p_rq p_rs}. Regarding deduction rule U2, the transition 
qo — — > qi is added to the transition relation of s/ g where qj = {(s=,,e), (s2,e\), (^2,^3)} (state 2 



3. 



in Figure 4(d) ). 

Following deduction rule 8\ and 8 out(s after e), 5-labeled transition is not added to qo. 



The constructed quotient automaton s/ s is valid: it is both a valid suspension automaton and strongly 
non-blocking. As a result, s is decomposable with respect to e and s/ e is a witness to that. 



5 Strong Decomposibility 

It is a natural question whether the quotient automaton that we defined in the previous section, along with 
the sufficient conditions for decomposability of a specification provide sufficient conditions for strong 
decomposability. The proof of Theorem [T] gives some clues to the contrary. A main problem is in the 
notion of quiescence, and, in particular in the notion of relative quiescence, which is unobservable in the 
standard ioco theory. More specifically, the platform e may mask the (unwanted) lack of outputs of the 
quotient automaton. 

A natural solution to this is to consider a subclass of implementations called internal choice IOTSs, 
studied in JU Q31 : such implementations only accept inputs when reaching a quiescent state. The propo- 
sition below states that strong decomposability can be achieved under these conditions. 

Theorem 2 Let s G IOLTS(/ v , U s ) be a specification and let e G IOTS(/ e , U e ) be an environment. Ifs is 
decomposable and e is an internal choice IOTS then s is strongly decomposable and s/g is a witness to 
this. 

As a result of the above theorem, testing whether the composition of a component c and a platform e 
conforms to specification s reduces to testing for the conformance of c to sj e . This can be done using the 
standard ioco testing theory lfT3l . 

A problem may arise when trying this approach in practice. Namely, the amount of time and mem- 
ory needed for derivation of the ioco test suit increases exponentially in the number of transitions in the 
specification due to the nondeterministic nature of the test-case generation algorithm. We avoid these 
complexities by presenting an on-the-fly testing algorithm inspired by [4]. Algorithm [T] describes the 
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on-the-fly testing algorithm in which sound test cases are generated without constructing the quotient 
automaton upfront. We partially explored the quotient automaton during test execution. We use the ex- 
tended version of executes operator in Algorithm[T]which is defined on ordinary IOLTSs; the underlying 
IOLTSs of suspension automata is used to avoid the complexity of constructing suspension automata, i.e. 
executes : P(P(S S ) x F(S e )) xL s x F(F(S S ) x F(S e )). 

Algorithm 1 Let s G lOLTS^, U s ) be a specification and let e G IOTS(/ e , U e ) be an environment. Let 

c G IOTS(L/,L[/) be an implementation tested against s with respect to e by application of the following 

rules, initializing S with ({(s after e), (e after £)}) and verdict V with None: 

while (V G" {Fail, Pass} ) 

{ apply one of the following case: 

1. (*provide an input*) Select an a G {a G L\ \ S executes a ^ 0}, then S = S executes a and provide 
c with a 

2. (* accept quiescence*) If no output is generated by c {quiescence situation) and 
V(s,e) G 5,(7 G Straces(s) nStraces(<?) : S G out(s after a) , then S = S executes S 

3. (*fail on quiescence*) If no output is generated by c (quiescence situation) and 
(3(s,e) G S, a G Straces(s) n Straces(e) : 8 G" out(s after a)), then V = Fail 

4. (*accept a shared output*) Ifx G U v is produced by c and S executes x ^ 0, then S = S executes x 

5. (*fail on a shared output*) Ifx G U v is produced by c and S executes x = 0, then V = Fail 

6. (*accept an output*) If x £U\U V is produced by c andV(s,e) G S, cx G Straces(i) n Straces(e) n 
(L* s \ L* S 8) : x G out(s after a), then S = S executes x 

7. (*fail on an output*) Ifx EU\U V is produced by c and 

3(s,e) G S,a G Straces(s)nStraces(e) n (L* S \L* S S) : x G" out(j after a), then V = Fail 

8. (*nondeterministically terminate*) V = Pass } 

Termination of the above algorithm with V = Fail implies that the composition of the implementation 
under test with e does not conform to s. 

Theorem 3 Let s G IOLTS(/ s , U s ) be a specification and let e G IOLTS(/ e , U e ) be an internal choice IOTS 
environment whose behavior is included in s. Let V be the verdict upon termination of Algorithm^when 
executed on an implementation c. 7f hide[L v ] inc||e ioco s then V = Pass. 

6 Conclusions 

We investigated the property of decomposability of a specification in the setting of Tretmans' ioco theory 
for formal conformance testing Ifl2l . Decomposability allows for determining whether a specification 
can be met by some implementation running on a given platform. Based on a new specification, to which 
we refer to as the quotient, and which we derived from the given one by factoring out the effects of 
the platform, we identified three conditions (two on the quotient and one on the platform) that together 
guarantee the decomposability of the original specification. 

Any component that correctly implements the quotient is guaranteed to work correctly on the given 
platform. However, failing implementations provide no information on the correctness of the cooper- 
ation between the component and the platform. We therefore studied strong decomposability, which 
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further strengthens the decomposability problem to ensure that only those components that correctly 
implement the quotient are guaranteed to work correctly on the given platform, meeting the overall spec- 
ification. This ensures that testing a component against the quotient provides all information needed to 
judge whether it will work correctly on the platform and meet the overall specification's requirements. 
However, the complexity of computing the quotient is an exponential problem. We propose an on-the-fly 
test case derivation algorithm which does not compute the quotient explicitly. Components that fail such 
a test case provably fail to work on the platform, meeting the overall specification, too. 

Checking the inclusion relation of a platform may be expensive in practice. As for future work, we 
would like to merge the two steps of checking the correctness of the platform and driving the quotient and 
investigate whether the constraints on the platform can be relaxed by ensuring that the derived quotient 
masks some of the unwanted behavior of the platform. 
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